No actionable comments were generated in the recent review. 🎉

sequenceDiagram
  participant HydrationSystem
  participant logMismatchError
  participant handleError
  participant AppErrorHandler
  participant ComponentCapture

  HydrationSystem->>logMismatchError: detect mismatch (parentComponent)
  logMismatchError->>logMismatchError: check hasLoggedMismatchError
  alt not logged
    logMismatchError->>logMismatchError: set hasLoggedMismatchError = true
    logMismatchError->>handleError: handleError(Error("Hydration completed but contains mismatches."), instance, ErrorCodes.HYDRATION_MISMATCH)
    handleError->>AppErrorHandler: invoke if configured
    handleError->>ComponentCapture: deliver to captured ancestor handlers (onErrorCaptured)
  else already logged
    logMismatchError->>logMismatchError: skip duplicate emission
  end

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Hi — friendly ping. Is this PR still on the radar for review? Happy to rebase or make changes if needed. Thanks!

I agree the observability use case is valid, but I don't think this should be merged in the current form.

Routing hydration mismatch reporting through handleError() changes the existing semantics: onErrorCaptured can now stop propagation, existing app.config.errorHandler hooks will start receiving hydration mismatches, and the fallback console behavior changes when there is no explicit consumer. So this is more of a minor feature than a bug fix.

I think the safer direction is to preserve the current default behavior and only expose hydration mismatch reporting to user handlers when there is an explicit consumer, or consider an app-level / warning-handler based API instead of putting it fully into the component error boundary pipeline.

Hi — friendly follow-up. CI is green and all checks pass. Would you be able to review when you get a chance? Thank you!

@edison1105 thanks for the careful review — fully agree. I just pushed a rework that addresses your concerns:

handleError is now gated on an explicit consumer. logMismatchError only routes through handleError(..., HYDRATION_MISMATCH, false) when one of the following is true on the parent component instance:

1. appContext.config.errorHandler is set, or
2. some ancestor component has registered onErrorCaptured.

Without a consumer, the per-mismatch warn() calls at the call sites remain the only output — which is exactly the prior default behavior. SSR apps that have not opted in see no "Unhandled error during execution of hydration" warning and no behavior change at all. Apps that have opted in (errorHandler / onErrorCaptured) get the integration with the error pipeline that issue #13154 asked for.

Other concerns:

• onErrorCaptured stopping propagation: only relevant when an ancestor has opted in by registering it. The default-no-consumer path is unchanged.
• Existing app.config.errorHandler hooks suddenly receiving hydration mismatches: fair point as a semantics change, but it requires the user to have explicitly set errorHandler and be doing SSR with mismatches; in that narrow case the new signal is what observability users ("Hydration completed but contains mismatches" error not caught by the Vue error handler #13154) want. Happy to add a release-note entry if you'd like.

Tests cover all four cases: errorHandler consumer, onErrorCaptured consumer, single-emit guard, and the no-consumer path (asserts "Unhandled error during execution of hydration" is not warned).

Let me know if the gating-on-consumer shape works for you, or if you'd prefer the app-level / warning-handler API instead — happy to iterate.

@pierluigilenoci @edison1105 Thanks for working on this. Any updates on your side that could help unblock it? Happy to help if needed.

@edison1105 thank you for the feedback — you're right that the previous revision dropped the production console.error fallback for apps without an explicit consumer.

I just pushed a fix that preserves the original default behavior exactly:

• With consumer (app.config.errorHandler or ancestor onErrorCaptured): routes through handleError(err, instance, ErrorCodes.HYDRATION_MISMATCH, false) — this is the new opt-in integration for observability tools.
• Without consumer: emits the same console.error('Hydration completed but contains mismatches.') as before — no behavior change for existing SSR apps.

The change is minimal: a single hasConsumer guard with an else branch that calls console.error(err.message) (matching the prior output). All 110 hydration tests pass, lint and type check are clean.

Let me know if this shape works for you.